Long Term Evolution (LTE)
Third-generation mobile systems (3G) based on WCDMA radio-access technology are being deployed on a broad scale all around the world. A first step in enhancing or evolving this technology entails introducing High-Speed Downlink Packet Access (HSDPA) and an enhanced uplink, also referred to as High Speed Uplink Packet Access (HSUPA), giving a radio access technology that is highly competitive.
In order to be prepared for further increasing user demands and to be competitive against new radio access technologies, 3GPP introduced a new mobile communication system which is called Long Term Evolution (LTE). LTE is designed to meet the carrier needs for high speed data and media transport as well as high capacity voice support for the next decade. The ability to provide high bit rates is a key measure for LTE.
The work item (WI) specification on Long-Term Evolution (LTE) called Evolved UMTS Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN) is finalized as Release 8 (LTE Rel. 8). The LTE system represents efficient packet-based radio access and radio access networks that provide full IP-based functionalities with low latency and low cost. In LTE, scalable multiple transmission bandwidths are specified such as 1.4, 3.0, 5.0, 10.0, 15.0, and 20.0 MHz, in order to achieve flexible system deployment using a given spectrum. In the downlink, Orthogonal Frequency Division Multiplexing (OFDM) based radio access was adopted because of its inherent immunity to multipath interference (MPI) due to a low symbol rate, the use of a cyclic prefix (CP) and its affinity to different transmission bandwidth arrangements. Single-carrier frequency division multiple access (SC-FDMA) based radio access was adopted in the uplink, since provisioning of wide area coverage was prioritized over improvement in the peak data rate considering the restricted transmit power of the user equipment (UE). Many key packet radio access techniques are employed including multiple-input multiple-output (MIMO) channel transmission techniques and a highly efficient control signaling structure is achieved in LTE Rel. 8/9.
LTE Architecture
The overall architecture is shown in FIG. 1 and a more detailed representation of the E-UTRAN architecture is given in FIG. 2. The E-UTRAN consists of an eNodeB, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the user equipment (UE). The eNodeB (eNB) hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC) and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated uplink Quality of Service (QoS), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of downlink/uplink user plane packet headers. The eNodeBs are interconnected with each other by means of the X2 interface.
The eNodeBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (SGW) by means of the S1-U. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNodeBs. The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state user equipment, the SGW terminates the downlink data path and triggers paging when downlink data arrives for the user equipment. It manages and stores user equipment contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode user equipment tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a user equipment at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to user equipment. It checks the authorization of the user equipment to camp on the service provider's Public Land Mobile Network (PLMN) and enforces user equipment roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming user equipment.
Component Carrier Structure in LTE
The downlink component carrier of a 3GPP LTE system is subdivided in the time-frequency domain in so-called sub-frames. In 3GPP LTE each sub-frame is divided into two downlink slots as shown in FIG. 3, wherein the first downlink slot comprises the control channel region (PDCCH region) within the first OFDM symbols. Each sub-frame consists of a give number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE (Release 8)), wherein each OFDM symbol spans over the entire bandwidth of the component carrier. The OFDM symbols thus each consists of a number of modulation symbols transmitted on respective NRBDL×NscRB subcarriers as also shown in FIG. 4.
Assuming a multi-carrier communication system, e.g. employing OFDM, as for example used in 3GPP Long Term Evolution (LTE), the smallest unit of resources that can be assigned by the scheduler is one “resource block”. A physical resource block (PRB) is defined as NsymbDL consecutive OFDM symbols in the time domain (e.g. 7 OFDM symbols) and NscRB subcarriers in the frequency domain as exemplified in FIG. 4 (e.g. 12 subcarriers for a component carrier). In 3GPP LTE (Release 8), a physical resource block thus consists of NsymbDL×NscRB resource elements, corresponding to one slot in the time domain and 180 kHz in the frequency domain (for further details on the downlink resource grid, see for example 3GPP TS 36.211, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)”, section 6.2, available at http://www.3gpp.org and incorporated herein by reference).
One sub-frame consists of two slots, so that there are 14 OFDM symbols in a sub-frame when a so-called “normal” CP (cyclic prefix) is used, and 12 OFDM symbols in a sub-frame when a so-called “extended” CP is used. For sake of terminology, in the following the time-frequency resources equivalent to the same NscRB subcarriers spanning a full sub-frame is called a “resource block pair”, or equivalent “RB pair” or “PRB pair”.
The term “component carrier” refers to a combination of several resource blocks in the frequency domain. In future releases of LTE, the term “component carrier” is no longer used; instead, the terminology is changed to “cell”, which refers to a combination of downlink and optionally uplink resources. The linking between the carrier frequency of the downlink resources and the carrier frequency of the uplink resources is indicated in the system information transmitted on the downlink resources.
Similar assumptions for the component carrier structure apply to later releases too.
Carrier Aggregation in LTE-A for Support of Wider Bandwidth
The frequency spectrum for IMT-Advanced was decided at the World Radio communication Conference 2007 (WRC-07). Although the overall frequency spectrum for IMT-Advanced was decided, the actual available frequency bandwidth is different according to each region or country. Following the decision on the available frequency spectrum outline, however, standardization of a radio interface started in the 3rd Generation Partnership Project (3GPP). At the 3GPP TSG RAN #39 meeting, the Study Item description on “Further Advancements for E-UTRA (LTE-Advanced)” was approved. The study item covers technology components to be considered for the evolution of E-UTRA, e.g. to fulfill the requirements on IMT-Advanced.
The bandwidth that the LTE-Advanced system is able to support is 100 MHz, while an LTE system can only support 20 MHz. Nowadays, the lack of radio spectrum has become a bottleneck of the development of wireless networks, and as a result it is difficult to find a spectrum band which is wide enough for the LTE-Advanced system. Consequently, it is urgent to find a way to gain a wider radio spectrum band, wherein a possible answer is the carrier aggregation functionality.
In carrier aggregation, two or more component carriers (component carriers) are aggregated in order to support wider transmission bandwidths up to 100 MHz. Several cells in the LTE system are aggregated into one wider channel in the LTE-Advanced system which is wide enough for 100 MHz even though these cells in LTE are in different frequency bands.
All component carriers can be configured to be LTE Rel. 8/9 compatible, at least when the aggregated numbers of component carriers in the uplink and the downlink are the same. Not all component carriers aggregated by a user equipment may necessarily be Rel. 8/9 compatible. Existing mechanism (e.g. barring) may be used to avoid Rel-8/9 user equipment to camp on a component carrier.
A user equipment may simultaneously receive or transmit one or multiple component carriers (corresponding to multiple serving cells) depending on its capabilities. A LTE-A Rel. 10 user equipment with reception and/or transmission capabilities for carrier aggregation can simultaneously receive and/or transmit on multiple serving cells, whereas an LTE Rel. 8/9 user equipment can receive and transmit on a single serving cell only, provided that the structure of the component carrier follows the Rel. 8/9 specifications.
Carrier aggregation is supported for both contiguous and non-contiguous component carriers with each component carrier limited to a maximum of 110 Resource Blocks in the frequency domain using the 3GPP LTE (Release 8/9) numerology.
It is possible to configure a 3GPP LTE-A (Release 10) compatible user equipment to aggregate a different number of component carriers originating from the same eNodeB (base station) and of possibly different bandwidths in the uplink and the downlink. The number of downlink component carriers that can be configured depends on the downlink aggregation capability of the UE. Conversely, the number of uplink component carriers that can be configured depends on the uplink aggregation capability of the UE. It may not be possible to configure a mobile terminal with more uplink component carriers than downlink component carriers.
In a typical TDD deployment, the number of component carriers and the bandwidth of each component carrier in uplink and downlink is the same. Component carriers originating from the same eNodeB need not to provide the same coverage.
The spacing between center frequencies of contiguously aggregated component carriers shall be a multiple of 300 kHz. This is in order to be compatible with the 100 kHz frequency raster of 3GPP LTE (Release 8/9) and at the same time preserve orthogonality of the subcarriers with 15 kHz spacing. Depending on the aggregation scenario, the n×300 kHz spacing can be facilitated by insertion of a low number of unused subcarriers between contiguous component carriers.
The nature of the aggregation of multiple carriers is only exposed up to the MAC layer. For both uplink and downlink there is one HARQ entity required in MAC for each aggregated component carrier. There is (in the absence of SU-MIMO for uplink) at most one transport block per component carrier. A transport block and its potential HARQ retransmissions need to be mapped on the same component carrier.
The Layer 2 structure with activated carrier aggregation is shown in FIG. 5 and FIG. 6 for the downlink and uplink respectively.
When carrier aggregation is configured, the mobile terminal only has one RRC connection with the network. At RRC connection establishment/re-establishment, one cell provides the security input (one ECGI, one PCI and one ARFCN) and the non-access stratum mobility information (e.g. TAI) similarly as in LTE Rel. 8/9. After RRC connection establishment/re-establishment, the component carrier corresponding to that cell is referred to as the downlink Primary Cell (PCell). There is always one and only one downlink PCell (DL PCell) and one uplink PCell (UL PCell) configured per user equipment in connected state. Within the configured set of component carriers, other cells are referred to as Secondary Cells (SCells); with carriers of the SCell being the Downlink Secondary Component Carrier (DL SCC) and Uplink Secondary Component Carrier (UL SCC). The characteristics of the downlink and uplink PCell are:
For each SCell the usage of uplink resources by the UE, in addition to the downlink ones is configurable; the number of DL SCCs configured is therefore always larger or equal to the number of UL SCCs, and no SCell can be configured for usage of uplink resources only
The uplink PCell is used for transmission of Layer 1 uplink control information
The downlink PCell cannot be de-activated, unlike SCells
From UE perspective, each uplink resource only belongs to one serving cell
The number of serving cells that can be configured depends on the aggregation capability of the UE
Re-establishment is triggered when the downlink PCell experiences Rayleigh fading (RLF), not when downlink SCells experience RLF
The downlink PCell cell can change with handover (i.e. with security key change and RACH procedure)
Non-access stratum information is taken from the downlink PCell
PCell can only be changed with handover procedure (i.e. with security key change and RACH procedure)
PCell is used for transmission of PUCCH
The configuration and reconfiguration of component carriers can be performed by RRC. Activation and deactivation is done via MAC control elements. At intra-LTE handover, RRC can also add, remove, or reconfigure SCells for usage in the target cell. When adding a new SCell, dedicated RRC signaling is used for sending the system information of the SCell, the information being necessary for transmission/reception (similarly as in Rel-8/9 for handover).
When a user equipment is configured with carrier aggregation there is one pair of uplink and downlink component carriers that is always active. The downlink component carrier of that pair might be also referred to as ‘DL anchor carrier’. Same applies also for the uplink.
When carrier aggregation is configured, a user equipment may be scheduled over multiple component carriers simultaneously but at most one random access procedure shall be ongoing at any time. Cross-carrier scheduling allows the PDCCH of a component carrier to schedule resources on another component carrier. For this purpose a component carrier identification field is introduced in the respective DCI formats, called CIF.
A linking between uplink and downlink component carriers allows identifying the uplink component carrier for which the grant applies when there is no cross-carrier scheduling. The linkage of downlink component carriers to uplink component carrier does not necessarily need to be one to one. In other words, more than one downlink component carrier can link to the same uplink component carrier. At the same time, a downlink component carrier can only link to one uplink component carrier.
Small Cell Deployment Scenarios
Explosive demands for mobile data are driving changes in how mobile operators will need to respond to the challenging requirements of higher capacity and improved Quality of user Experience (QoE). Currently, fourth generation wireless access systems using Long Term Evolution (LTE) are being deployed by many operators worldwide in order to offer faster access with lower latency and more efficiency than 3G/3.5G system.
The anticipated future traffic growth is so tremendous that there is a vastly increased need for further network densification to handle the capacity requirements, particularly in high traffic areas (hot spot areas) that generate the highest volume of traffic. Network densification—increasing the number of network nodes, thereby bringing them physically closer to the user terminals—is a key to improving traffic capacity and extending the achievable user-data rates of a wireless communication system.
In addition to straightforward densification of a macro deployment, network densification can be achieved by the deployment of complementary low-power nodes respectively small cells under the coverage of an existing macro-node layer. In such a heterogeneous deployment, the low-power nodes provide very high traffic capacity and very high user throughput locally, for example in indoor and outdoor hotspot locations. Meanwhile, the macro layer ensures service availability and QoE over the entire coverage area. In other words, the layer containing the low-power nodes can also be referred to as providing local-area access, in contrast to the wide-area-covering macro layer.
The installation of low-power nodes respectively small cells as well as heterogeneous deployments has been possible since the first release of LTE. In this regard, a number of solutions have been specified in recent releases of LTE (i.e., Release-10/11). More specifically, these recent releases introduced additional tools to handle inter-layer interference in heterogeneous deployments. In order to further optimize performance and provide cost/energy-efficient operation, small cells require further enhancements and in many cases need to interact with or complement existing macro cells.
Such optimizations are to be investigated as part of the further evolution of LTE—Release 12 and beyond. In particular further enhancements related to low-power nodes and heterogeneous deployments will be considered under the umbrella of the new Rel-12 study item (SI) “Study on Small Cell Enhancements for E-UTRA and E-UTRAN”. Some of these activities will focus on achieving an even higher degree of interworking between the macro and low-power layers, including different forms of macro assistance to the low-power layer and dual-layer connectivity. Dual connectivity implies that the device has simultaneous connections to both macro and low-power layers.
Dual Connectivity
One promising solution to the problems which are currently under discussion in 3GPP RAN working groups is the so-called dual connectivity concept. Dual connectivity is used to refer to an operation where a given UE consumes radio resources provided by at least two different network nodes connected via a non-ideal backhaul.
In other words, in dual connectivity the UE is connected with both a macro cell (master or macro eNB) and small cell (secondary or small eNB). Furthermore, each eNB involved in dual connectivity for a UE may assume different roles. Those roles do not necessarily depend on the eNB's power class and can vary among UEs.
For use of a consistent terminology, reference is made to Stage 2 description (3GPP R2-140906) of Small Cell Enhancement in LTE where the following terms are defined as follows. A Master Cell Group, MCG, in dual connectivity describes a group of serving cells associated with the MeNB, comprising of the PCell and optionally one or more SCells. The master eNB in dual connectivity identifies the eNB which terminates at least S1-MME. In this respect, the term MCG bearer in dual connectivity refers to radio protocols only located in the MeNB to use MeNB resources.
Similarly, a Secondary Cell Group, SCG in dual connectivity describes a group of serving cells associated with the SeNB comprising of the special SCell and optionally one or more SCells. The secondary eNB in dual connectivity identifies the eNB that is providing additional radio resources for the UE but is not the Master eNB. In this respect, the term SCG bearer in dual connectivity refers to radio protocols only located in the secondary eNB to use secondary eNB resources.
Since the study item is currently at a very early stage, details on the deployment of dual connectivity are yet to be decided. For example, different architectures are still actively discussed and, hence, may influence implementation aspects of dual connectivity. Therefore, many issues/details, e.g. protocol enhancements, are still open for further development.
FIG. 7 shows an exemplary architecture for dual connectivity. Specifically, an architecture is illustrated which corresponds to what is currently understood as Architecture 1A. In this Architecture 1A, S1-U terminates in the master eNB and in the secondary eNB and the S1-MME is terminated in the master eNB.
Both the master eNB and the secondary eNB provide independently the functionality of the Packet Data Convergence Protocol (PDCP) such that the illustrated Architecture 1A is not necessary to provide split bearers, i.e. where the a bearer is split over the master eNB and the secondary eNB.
In general, it should be understood the depicted dual connectivity architecture 1A is only one among many options for realizing dual connectivity. Moreover, the concept of dual connectivity applies the following assumptions on the architecture:
Per bearer level decision where to serve each packet, C/U plane split
As an example UE RRC signaling and high QoS data such as VoLTE can be served by the Macro cell, while best effort data is offloaded to the small cell.
No coupling between bearers, so no common PDCP or RLC required between the Macro cell and small cell
Looser coordination between RAN nodes SeNB has no connection to S-GW, i.e. packets are forwarded by MeNB
Small Cell is transparent to CN.
Regarding the last two bullet points, it should be noted that it's also possible that SeNB is connected directly with the S-GW, i.e. S1-U is between S-GW and SeNB. Essentially, there are three different options w.r.t. the bearer mapping/splitting:                Option 1: S1-U also terminates in SeNB, as; depicted in FIG. 7;        Option 2: S1-U terminates in MeNB, no bearer split in RAN; and        Option 3: S1-U terminates in MeNB, bearer split in RAN.Security        
Security is a very important feature of 3GPP LTE and in 3GPP TS 33.401: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security architecture (Release 12)”, Version 12.10.0, section 4, available at http://www.3gpp.org and incorporated herein by reference, defines five security feature groups. Each of these feature groups meets certain threats and accomplishes certain security objectives:                Network access security (I) relates to the set of security features that provide users with secure access to services, and which in particular protect against attacks on the (radio) access link.        Network domain security (II) relates to the set of security features that enable nodes to securely exchange signaling data, user data (between AN and SN and within AN), and protect against attacks on the wireline network.        User domain security (III) relates to the set of security features that secure access to mobile stations.        Application domain security (IV) relates to the set of security features that enable applications in the user and in the provider domain to securely exchange messages.        Visibility and configurability of security (V) relates to the set of features that enables the user to inform himself whether a security feature is in operation or not and whether the use and provision of services should depend on the security feature.        
The security objectives are illustrated in FIG. 8 with regard to the interaction between units and between functional layers in LTE. In the remaining document, the discussion focuses on network access security.
User Data (and Signaling Data) Confidentiality: Ciphering
The user data (and signaling data) must be ciphered. The User plane confidentiality protection shall be done at PDCP layer and is an operator option. The user plane data is ciphered by the PDCP protocol between the UE and the eNB as specified in 3GPP TS 36.323: “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Release 11)”, Version 11.2.0, section 5.6, available at http://www.3gpp.org and incorporated herein by reference.
Requirements for Handling User Plane Date for the eNB
It is eNB's task to cipher and decipher user plane packets between the Uu reference point and the S1/X2 reference points and to handle integrity protection for user plane packets for the S1/X2 reference points.
1. User plane data ciphering/deciphering and integrity handling shall take place inside the secure environment where the related keys are stored.
2. The transport of user data over S1-U and X2-U shall be integrity, confidentially and replay-protected from unauthorized parties. If this is to be accomplished by cryptographic means, clause 12 shall be applied except for the Un interface between RN and DeNB.
Requirements for Handling Control Plane Date for the eNB
It is eNB's task to provide confidentiality and integrity protection for control plane packets on the S1/X2 reference points.
1. Control plane data ciphering/deciphering and integrity handling shall take place inside the secure environment where the related keys are stored.
2. The transport of control plane data over S1-MME and X2-C shall be integrity-, confidentiality- and replay-protected from unauthorized parties. If this is to be accomplished by cryptographic means, clause 11 shall be applied except for the Un interface between RN and DeNB.
EPS Key Hierarchy
Requirements on EPC and E-UTRAN related to keys:
a) The EPC and E-UTRAN shall allow for use of encryption and integrity protection algorithms for AS and NAS protection having keys of length 128 bits and for future use the network interfaces shall be prepared to support 256 bit keys.
b) The keys used for UP, NAS and AS protection shall be dependent on the algorithm with which they are used.
The key hierarchy is shown in FIG. 9 includes following keys: KeNB, KNASint, KNASenc, KUPenc, KRRCint and KRRCenc. In the following, reference is made to a Key Derivation Function, KDF, which is specified in Annex A.7 of 3GPP TS 33.401: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security architecture (Release 12)”, Version 12.10.0, section 4, available at http://www.3gpp.org and incorporated herein by reference.
KeNB is a key derived by ME and MME from KASME or by ME and target eNB.
Keys for NAS traffic:
KNASint is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm This key is derived by ME and MME from KASME, as well as an identifier for the integrity algorithm using the KDF.
KNASenc is a key, which shall only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by ME and MME from KASME, as well as an identifier for the encryption algorithm using the KDF.
Keys for UP traffic:
KUPenc is a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by ME and eNB from KeNB, as well as an identifier for the encryption algorithm using the KDF.
KUPint is a key, which shall only be used for the protection of UP traffic between RN and DeNB with a particular integrity algorithm. This key is derived by RN and DeNB from KeNB, as well as an identifier for the integrity algorithm using the KDF.
Keys for RRC traffic:
KRRCint is a key, which shall only be used for the protection of RRC traffic with a particular integrity algorithm. KRRCint is derived by ME and eNB from KeNB, as well as an identifier for the integrity algorithm using the KDF.
KRRCenc is a key, which shall only be used for the protection of RRC traffic with a particular encryption algorithm. KRRCenc is derived by ME and eNB from KeNB as well as an identifier for the encryption algorithm using the KDF.
Intermediate keys:
NH, referring to the Next Hop parameter, is a key derived by ME and MME to provide forward security.
KeNB* is a key derived by ME and eNB when performing a horizontal or vertical key derivation.
Specifically, the key handling in handover is described in section 7.2.8 of 3GPP TS 33.401: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security architecture (Release 12)”, Version 12.10.0, available at http://www.3gpp.org and incorporated herein by reference.
For Dual Connectivity, S-KeNB will be derived from the KeNB and a “freshness parameter” which will be for example be 16 bit long.
Intra-eNB Handover
When the eNB decides to perform an intra-eNB handover it shall derive KeNB* as in Annex A.5 using target PCI, its frequency EARFCN-DL, and either NH or the current KeNB depending on the following criteria: the eNB shall use the NH for deriving KeNB* if an unused {NH, NCC} pair is available in the eNB (this is referred to as a vertical key derivation), otherwise if no unused {NH, NCC} pair is available in the eNB, the eNB shall derive KeNB* from the current KeNB (this is referred to as a horizontal key derivation).
The eNB shall use the KeNB* as the KeNB after handover. The eNB shall send the NCC used for KeNB* derivation to UE in HO Command message.
X2-Hanover
As in intra-eNB handovers, for X2 handovers the source eNB shall perform a vertical key derivation in case it has an unused {NH, NCC} pair. The source eNB shall first compute KeNB* from target PCI, its frequency EARFCN-DL, and either from currently active KeNB in case of horizontal key derivation or from the NH in case of vertical key derivation as described in Annex A.5 of 3GPP TS 33.401: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security architecture (Release 12)”, Version 12.10.0, available at http://www.3gpp.org and incorporated herein by reference.
Next the source eNB shall forward the {KeNB*, NCC} pair to the target eNB. The target eNB shall use the received KeNB* directly as KeNB to be used with the UE. The target eNB shall associate the NCC value received from source eNB with the KeNB. The target eNB shall include the received NCC into the prepared HO Command message, which is sent back to the source eNB in a transparent container and forwarded to the UE by source eNB.
When the target eNB has completed the handover signaling with the UE, it shall send a S1 PATH SWITCH REQUEST to the MME. Upon reception of the S1 PATH SWITCH REQUEST, the MME shall increase its locally kept NCC value by one and compute a new fresh NH by using the KASME and its locally kept NH value as input to the function defined in Annex A.4. The MME shall then send the newly computed {NH, NCC} pair to the target eNB in the S1 PATH SWITCH REQUEST ACKNOWLEDGE message. The target eNB shall store the received {NH, NCC} pair for further handovers and remove other existing unused stored {NH, NCC} pairs if any.
KeNB Refresh
This procedure is based on an intra-cell handover. The KeNB chaining that is performed during a handover ensures that the KeNB is refreshed with respect to the RRC and UP COUNT after the procedure.
128-bit Ciphering Algorithm
Inputs and Outputs
The input parameters to the ciphering algorithm are a 128-bit cipher key named KEY, a 32-bit COUNT, a 5-bit bearer identity BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the length of the keystream required i.e. LENGTH. The DIRECTION bit shall be 0 for uplink and 1 for downlink.
FIG. 10 illustrates the use of the ciphering algorithm EEA to encrypt plaintext by applying a keystream using a bit per bit binary addition of the plaintext and the keystream. The plaintext may be recovered by generating the same keystream using the same input parameters and applying a bit per bit binary addition with the ciphertext.
The use and mode of operation of the 128-EEA algorithms are specified in Annex B of 3GPP TS 33.401: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security architecture (Release 12)”, Version 12.10.0, available at http://www.3gpp.org and incorporated herein by reference.
The input parameters to the 128-bit EEA algorithms are an 128-bit cipher key KUPenc as KEY, a 5-bit bearer identity BEARER which value is assigned as specified by PDCP, the 1-bit direction of transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.
Based on the input parameters the algorithm generates the output keystream block KEYSTREAM which is used to encrypt the input plaintext block PLAINTEXT to produce the output ciphertext block CIPHERTEXT. The input parameter LENGTH shall affect only the length of the KEYSTREAM BLOCK, not the actual bits in it.
Shortcomings of Prior Art Power Control
In dual connectivity, the security key S-KeNB is applicable to network access security for the secondary base station, SeNB and is comparable in its functionality to security key KeNB for the master base station, MeNB. The derivation of this security key S-KeNB shall be explained in connection with FIG. 12.
The master base station, MeNB, derives, in step 3, this security key S-KeNB for the communication between the mobile terminal and the secondary base station from the security key KeNB and a “Counter” value. Subsequently, the derived S-KeNB is transmitted by the master base station, MeNB, in step 4, to the secondary base station, SeNB. Thereafter, the secondary base station, SeNB derives, in step 5, the UP-encryption keys S-KUPenc, and optionally integrity protection key S-KUPint, from this S-KeNB. Specifically, the SeNB derives further the UP-integrity keys from this S-KeNB (and if required the integrity keys for RRC Signaling and User plane and also the RRC-encryption keys). The Counter is a new 16 bit (or perhaps a different length) counter and is known as “freshness parameter”.
As seen from FIG. 10, for the ciphering/encryption apart from KEY (KeNB/S-KeNB), four other input parameters are prescribed for the ciphering operation of data. Security is based on the principle that all five input parameters all should not be the same for subsequent ciphering. If they are, it represents a potential security threat. Input parameters COUNT, DIRECTION and LENGTH do not allow much degree of freedom for eNB to choose/change between different values; e.g. For UL data ciphering, the DIRECTION has to indicate “UL”. For DL data ciphering, the DIRECTION has to indicate “DL”.
A problem results from situations when the bearer identification (i.e. RB-id) is to be reused as the BEARER input parameter to the ciphering/encryption (e.g. a same RB-id is allocated to a new bearer). A similar problem results from situations where COUNT would wrap-up (for a same BEARER). In these situations, if the KEY (KeNB/S-KeNB) would remain the same, then it would lead to a repetition in the input parameters. Such a repetition in the input parameters to the ciphering/encryption represents a security hole that can be exploited. For example, RB-id reuse security hole can be exploited by an attacker quickly adding more and more application.
For ciphering and integrity a COUNT value is maintained which is shown in FIG. 11. The COUNT value is composed of a HFN and the PDCP sequence number, SN. The length of the PDCP SN is configured by upper layers. The PDCP SN is bearer specific which means that for each radio bearer, a separate PDCP SN is maintained. The size of the HFN part in bits is equal to 32 minus the length of the PDCP SN. COUNT wrap-up would happen when the number of PDCP PDUs transmitted exceeds the total length of COUNT.
Bearer (RB-id) reuse (same RB-id being allocated to a new bearer) could happen in the following situations: Firstly, a bearer release and later same RB-id (especially a DRB) being allocated to a different bearer. A DRB-id is the RB-id allocated to a Data Bearer (DRB). Secondly, when DRB-id space is wrapped i.e. 29 DRBs in LTE (32−3 SRBs) were established and a new Bearer will need to use one of the already used DRB-id. A total of 32 Bearers can be configured to a UE in LTE out of which 3 bearers (and corresponding Ids) are reserved for Signaling, called Signaling Radio Bearer.
Since dual connectivity has not yet been standardized, the above discussed problems are new and there are no solutions available in specification. However, based on the principles in legacy (e.g. LTE Rel. 11 and before) an eNB avoids RB-id reuse as much as possible. However, there may be a point beyond which the situation (RB-id reuse or COUNT wrap-up) cannot be avoided anymore.
When avoiding is no more possible/is difficult, the MeNB may perform Intra-cell handover which changes the KeNB to be used in the MeNB (MCG) but further it is not clear how it will lead to refreshing of S-KeNB. When/if the new KeNB is used to refresh the S-KeNB, the MeNB bearers also get interrupted unnecessarily since the refresh of KeNB was only a means of refreshing S-KeNB but was not required otherwise (no RB-id reuse or COUNT wrap-up for the bearers being served by MeNB directly). Further, Intra-cell handover is quite expensive procedure since it involves some interruption of user data not only in SeNB but also in MeNB. Interruption of user data for MeNB only bearers is quite un-necessary/avoidable since this is mainly a security issue at the SeNB.
As a result of Intra-cell handover all the bearer(s) needs to be re-established and data forwarded between the network nodes, etc. So this is better avoided or optimized.
Dual Connectivity introduces more than one eNB to UE's connection i.e. the UE consumes/utilizes resources from two eNBs. Both security protect the signaling and/or data towards the UE with their respective keys; MeNB with KeNB and SeNB with S-KeNB.